Path computation for tunnels of a computer network, e.g., label switched paths (LSPs), may be performed by head-end nodes of the tunnels, or by specialized Path Computation Elements (PCEs). For example, tunnels in many Multi-Protocol Label Switching (MPLS) Traffic Engineering (TE) networks (e.g., MPLS TE-LSPs) are computed using a constrained shortest path first (CSPF) algorithm, which offers high flexibility/scalability, and is well-equipped to handle frequent topology changes, dynamic traffic demands, and resource availability changes. While head-end nodes of tunnels may often be equipped to compute a suitable path for a tunnel, PCEs offer a variety of benefits not generally available to head-end nodes. For instance, PCEs may have advanced knowledge of the network topology, such as knowledge of existing tunnels through the network of which the head-end nodes may not be aware, visibility in other domains, etc. In addition, PCEs may be configured to communicate with other PCEs, such as for inter-domain (inter-area and/or inter-Autonomous-System, “inter-AS”) path computation.
Accordingly, a path computation client (PCC), such as a head-end node, may send a request to a locally-reachable PCE to compute a path for a tunnel to one or more desired destinations (e.g., possibly with one or more constraints, as will be understood by those skilled in the art). In situations where a destination is beyond the knowledge of the local PCE, the local PCE may forward the request to a remote (next-hop/downstream) PCE, e.g., in a different domain, to continue the computation of the path; thus the local PCE acts as a PCC to the cooperating remote PCE. The remote PCE may further forward the request to other remote PCEs toward the destination and so on, until a final PCE (local to the destination) is reached. Each remote PCE may then return its local portion of one or more computed paths to its upstream PCE (that is, the PCC from which each PCE received the forwarded request), which may then compute its respective portion based on the received portions of the computed path(s). In this manner, a “path computation chain” or “PCE chain” is established, i.e., along a path of PCEs used to compute the path to the destination (e.g., also referred to as “recursive path computation,” as may be understood by those skilled in the art).
Operations Administration Management (or Maintenance) (OAM) tools, as will be understood by those skilled in the art, may be used to provide system or network fault indication, performance monitoring, security management, diagnostic functions, etc. Currently, however, there are no known end-to-end OAM tools available to obtain performance metrics and/or other information from PCEs along particular PCE (path computation) chains. For example, occasionally, a path computation request will fail or will be delayed for an extended period of time. It may be beneficial to determine the cause of the failure/delay, such as which particular PCE is the cause/bottleneck, what is the cause, etc. By determining the cause(s), a PCC may be able to more efficiently select a PCE (or set of PCEs), such as PCEs that are operational/functional and/or are less of a bottleneck, etc. Also, such a set of OAM tools for PCE chains may be useful for general network management, such as where performance metrics of the PCE chains are particularly difficult/challenging to monitor (e.g., inter-domain chains). There remains a need, therefore, for OAM for PCE (path computation) chains.